inbox cleaning

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

inbox cleaning

Torsten Bergmann
Hi Stephane,

the MCZ's for
HelpSystem-Core-tbn.45
HelpSystem-Core-tbn.43

were already harvested. So shouldnt this be moved
to treated inbox then?

Thx
T.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: inbox cleaning

Stéphane Ducasse
Yes!
I clean but this is really tedious

stef

On May 20, 2010, at 11:57 AM, Torsten Bergmann wrote:

> Hi Stephane,
>
> the MCZ's for
> HelpSystem-Core-tbn.45
> HelpSystem-Core-tbn.43
>
> were already harvested. So shouldnt this be moved
> to treated inbox then?
>
> Thx
> T.
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: inbox cleaning

laurent laffont
I was thinking about following rules to make life easier:
- a submission in PharoInbox must be a slice
- slice must be formatted like LabelOfPatch-IssueNumber
for example:
BadCharactersInPackagenames-2124
PerformWithArgsPrimFailure-2443
- reject automatically slices which don't follow the name convention

Then
- it's easy to build an interface which shows queued patches (filter by package name)
- it's easy to clean PharoInbox / delete required packages
- more visibility to the contribution process, one way of doing things (so we can automate - hudson server which test patch integration :)

What do you think ? 

Laurent Laffont

http://pharocasts.blogspot.com/
http://magaloma.blogspot.com/


On Thu, May 20, 2010 at 2:31 PM, Stéphane Ducasse <[hidden email]> wrote:
Yes!
I clean but this is really tedious

stef

On May 20, 2010, at 11:57 AM, Torsten Bergmann wrote:

> Hi Stephane,
>
> the MCZ's for
> HelpSystem-Core-tbn.45
> HelpSystem-Core-tbn.43
>
> were already harvested. So shouldnt this be moved
> to treated inbox then?
>
> Thx
> T.
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: inbox cleaning

Stéphane Ducasse

On May 20, 2010, at 3:03 PM, laurent laffont wrote:

> I was thinking about following rules to make life easier:
> - a submission in PharoInbox must be a slice
> - slice must be formatted like LabelOfPatch-IssueNumber
> for example:
> BadCharactersInPackagenames-2124
> PerformWithArgsPrimFailure-2443
> - reject automatically slices which don't follow the name convention
>
> Then
> - it's easy to build an interface which shows queued patches (filter by package name)
> - it's easy to clean PharoInbox / delete required packages
> - more visibility to the contribution process, one way of doing things (so we can automate - hudson server which test patch integration :)
>
> What do you think ?

I like the idea.
I need a server that we can script.

> Laurent Laffont
>
> http://pharocasts.blogspot.com/
> http://magaloma.blogspot.com/
>
>
> On Thu, May 20, 2010 at 2:31 PM, Stéphane Ducasse <[hidden email]> wrote:
> Yes!
> I clean but this is really tedious
>
> stef
>
> On May 20, 2010, at 11:57 AM, Torsten Bergmann wrote:
>
> > Hi Stephane,
> >
> > the MCZ's for
> > HelpSystem-Core-tbn.45
> > HelpSystem-Core-tbn.43
> >
> > were already harvested. So shouldnt this be moved
> > to treated inbox then?
> >
> > Thx
> > T.
> > --
> > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: inbox cleaning

Henrik Sperre Johansen
In reply to this post by laurent laffont
FWIW, there's already kind of a process described at http://code.google.com/p/pharo/wiki/HowToContribute

I do agree with you on some things which could/should be changed though:

On May 20, 2010, at 3:03 09PM, laurent laffont wrote:

> I was thinking about following rules to make life easier:
> - a submission in PharoInbox must be a slice
+1.
Makes it much easier to scan the inbox for related package when an issue has been marked as fixed and in Inbox.
Even when it only effects a single package (as the page states as an exception to the slice-rule)

> - slice must be formatted like LabelOfPatch-IssueNumber
> for example:
> BadCharactersInPackagenames-2124
> PerformWithArgsPrimFailure-2443
> - reject automatically slices which don't follow the name convention

I sort of prefer:
SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix)
That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inbox, but need to know which issues are safe to close.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: inbox cleaning

laurent laffont
On Thu, May 20, 2010 at 3:17 PM, Henrik Johansen <[hidden email]> wrote:
FWIW, there's already kind of a process described at http://code.google.com/p/pharo/wiki/HowToContribute

I do agree with you on some things which could/should be changed though:

On May 20, 2010, at 3:03 09PM, laurent laffont wrote:

> I was thinking about following rules to make life easier:
> - a submission in PharoInbox must be a slice
+1.
Makes it much easier to scan the inbox for related package when an issue has been marked as fixed and in Inbox.
Even when it only effects a single package (as the page states as an exception to the slice-rule)

> - slice must be formatted like LabelOfPatch-IssueNumber
> for example:
> BadCharactersInPackagenames-2124
> PerformWithArgsPrimFailure-2443
> - reject automatically slices which don't follow the name convention

I sort of prefer:
SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix)
That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inbox, but need to know which issues are safe to close.

Yes, better to have the number before. Maybe we can remove the word slice too:  XYZM-DescriptionOfIssue.

I think the real trick is to reject (kindly, with lot of explanations :) all slices which do not follow the adopted convention so people follow the rule.
 
We can create a PharoRejected repository to let people know. Then some Smalltalk code scans PharoInbox, move bad formatted slices to PharoRejected automatically. In PharoRejected packages are deleted after 2 weeks for example.

Laurent

 
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: inbox cleaning

Stéphane Ducasse
In reply to this post by Henrik Sperre Johansen
Me tooooooooooo
>
> I sort of prefer:
> SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix)
> That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inb

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: inbox cleaning

Mariano Martinez Peck
I think all this have sense in the automate it. So, I would use Gofer (if possible) to script such things.

If you have that, then call it from Hudson should be easy.

But please, please, please, if we change this, we need to change all the documents and website where we explain the submit code steps. For example, there we say that if you only touch one package, no need of a slice. And even the name of the slice may change (as I read here).

Cheers

Mariano

On Thu, May 20, 2010 at 4:19 PM, Stéphane Ducasse <[hidden email]> wrote:
Me tooooooooooo
>
> I sort of prefer:
> SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix)
> That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inb

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project