Re: [E-devel] Release Handling
Okay, we need to step back with this a bit. The problem is, workboards are quite unmanagable, and clearly not made for the amount of tickets we are having. So here a new proposal: I create the following projects: efl-ecore (additionally: elput & ecore_*) efl-eina (additionally: evil emile) efl-eo efl-eolian efl-edje (additionally: ephysics embryo) efl-evas (additionally ector) efl-elementary (additionally: ethumb, emotion & elocation) efl-eldbus efl-eio efl-efreet efl-sys (additionally: eeze) efl-eet Each project gets automatically added efl to it. The tags can be added to each ticket. Opinions? Greetings, bu5hm4n On 06/11/2018 05:54 AM, Hermet Park wrote: good to go. On Sat, Jun 9, 2018 at 12:47 AM, Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: This seems like something which would help people more easily find issues that they can contribute to. Perhaps a 5th workboard for something like 'main loop' could also be added? On Fri, Jun 8, 2018 at 11:32 AM Marcel Hollerbach wrote: Hello, as Mike said, here my proposal for handling bugs for the upcoming release: i) Every bug will get a difficulty assigned either Easy, Difficult, or Impossible, this is to ensure that new people, and people that don't know the subsystem or context very well can also help bugfixing. ii) I am going to create 4 new workboards: - primitives: Stuff that has its root problems in eina, eo, (low in our software stack) - interfaces: A Bug is caused due to the movement to a different namespace, refactoring into new classes, or changes related to new efl_* code / classes. - rendering: A Bug is located in the engine code for some protocol/platform - widgets: Your usage of elm widgets broke somewhere between efl-1.20 and the current state. iii) If you work on a bug, claim it for you. If a other bug sneaks in between, or there is no time in the next week or so: Document your findings, and remove your name from the assignee field on phabricator, so someone else might work on the bug. Any objections ? For Monday I am planning to go through the bugtracker trying to assign difficulities, and workboards. Greetings, bu5hm4n -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release Handling
Imho, base infrastructure (eo/eina/efl) / rendering (evas, ector) / layout (edje, eet) / core system (ecore family) / window system / widgets (elm) / sys-helpers (efreet, eldbus, eeze... ) is enough ... But, your proposal is not arguable neither. I agree on it. The problem is, sometimes issues aren't independent by modules nor clear to list up... anyway, good to go! On Mon, Jun 11, 2018 at 4:26 PM, Marcel Hollerbach wrote: > Okay, we need to step back with this a bit. > > The problem is, workboards are quite unmanagable, and clearly not made for > the amount of tickets we are having. > > So here a new proposal: > I create the following projects: > > efl-ecore (additionally: elput & ecore_*) > efl-eina (additionally: evil emile) > efl-eo > efl-eolian > efl-edje (additionally: ephysics embryo) > efl-evas (additionally ector) > efl-elementary (additionally: ethumb, emotion & elocation) > efl-eldbus > efl-eio > efl-efreet > efl-sys (additionally: eeze) > efl-eet > > Each project gets automatically added efl to it. The tags can be added to > each ticket. > > Opinions? > > Greetings, >bu5hm4n > > > On 06/11/2018 05:54 AM, Hermet Park wrote: > >> good to go. >> >> On Sat, Jun 9, 2018 at 12:47 AM, Mike Blumenkrantz < >> michael.blumenkra...@gmail.com> wrote: >> >> This seems like something which would help people more easily find issues >>> that they can contribute to. Perhaps a 5th workboard for something like >>> 'main loop' could also be added? >>> >>> On Fri, Jun 8, 2018 at 11:32 AM Marcel Hollerbach >>> wrote: >>> >>> Hello, as Mike said, here my proposal for handling bugs for the upcoming >>> release: >>> i) Every bug will get a difficulty assigned either Easy, Difficult, or Impossible, this is to ensure that new people, and people that don't know the subsystem or context very well can also help bugfixing. ii) I am going to create 4 new workboards: - primitives: Stuff that has its root problems in eina, eo, (low in our software stack) - interfaces: A Bug is caused due to the movement to a different namespace, refactoring into new classes, or changes related to new efl_* code / classes. - rendering: A Bug is located in the engine code for some >>> protocol/platform >>> - widgets: Your usage of elm widgets broke somewhere between efl-1.20 and the current state. iii) If you work on a bug, claim it for you. If a other bug sneaks in between, or there is no time in the next week or so: Document your findings, and remove your name from the assignee field on phabricator, so someone else might work on the bug. Any objections ? For Monday I am planning to go through the bugtracker trying to assign difficulities, and workboards. Greetings, bu5hm4n >>> -- >>> Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> ___ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >>> >> >> >> > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Regards, Hermet -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Freeze
I'm not sure we have a schedule (or can abide by it if one exists)? I think perhaps we should try for an alpha release within the next 1-2 weeks to get some broader testing, but a separate mail thread can be created to discuss this... On Mon, Jun 11, 2018 at 12:11 AM Hermet Park wrote: > +1, btw, I didn't catch the freeze period. What is the next release date we > are expecting to ? it just depends on all fixes bugs listed up? > > On Sat, Jun 9, 2018 at 3:40 AM, Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > Sure, I agree with what you are saying but this is still a bit subjective > > and so I don't think there is a need to attempt to codify that in the > form > > of a policy. Even if a major feature is merged during a freeze which > seems > > unnecessary (e.g., adding some giant new widget) then it's quite easy for > > the community to come together and vote to remove it until after the > > release occurs. All features added during freeze must go through patch > > review based on this proposal, and all core developers are automatically > > assigned to all efl patch submissions so it is impossible to be unaware > of > > things like this going forward. > > > > I think everyone in non-western countries is likely asleep now, but if > > there is no strong dissent by end of day Monday then we can continue with > > this course of action and begin preparing the release in earnest. > > > > On Fri, Jun 8, 2018 at 2:24 PM Felipe Magno de Almeida < > > felipe.m.alme...@gmail.com> wrote: > > > > > On Fri, Jun 8, 2018 at 2:35 PM, Mike Blumenkrantz > > > wrote: > > > > I'm opposed to having a blanket policy that there can be no new > > features > > > at > > > > all added during a freeze. > > > > > > > > As an example, https://phab.enlightenment.org/D6247 is a feature > which > > > is > > > > required in order to improve test reliability--something which should > > be > > > at > > > > the top of the list when working on a release. A strict "no features > at > > > > all" policy would prevent this from being merged until after the > > release, > > > > leading to unreliable testing during the release cycle. This level of > > > > pedantry is not beneficial to the project. > > > > > > I agree. > > > > > > > A freeze should mean that features are not likely to be added. It > > should > > > > not, however, mean that features cannot be added. Having a strict > > policy > > > > for this case does nothing more than establish such a policy for the > > sake > > > > of having a strict policy instead of having a policy which benefits > the > > > > project. Anyone electing to merge features during the freeze should > be > > > > cognizant of this, and should also be aware that the rest of the > > > community > > > > may disagree and overrule the decision. > > > > > > I think I expressed myself stricter than necessary. I think new > > > features that aren't going to improve *correctness* should not be > > > considered. A feature that helps fix bugs could be considered > > > if it delivers a release with less bugs. > > > > > > Regards, > > > -- > > > Felipe Magno de Almeida > > > > > > > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > Regards, Hermet > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release Handling
Mike came up with the idea of sub projects, which sounds very good to me. On 06/11/2018 10:17 AM, Hermet Park wrote: Imho, base infrastructure (eo/eina/efl) / rendering (evas, ector) / layout (edje, eet) / core system (ecore family) / window system / widgets (elm) / sys-helpers (efreet, eldbus, eeze... ) is enough ... Probably true, however, i would like to have them in even smaller projects, so its easier to find relevant tickets for one specific subsystem ... :) I think a project with 10 tickets is easier to maintain and look at instead of 100 tickets ... :) But, your proposal is not arguable neither. I agree on it. The problem is, sometimes issues aren't independent by modules nor clear to list up... That is the reason i want to use projects tags now, you can add multiple projects (like efl-ecore efl-evas efl-elementary). anyway, good to go! Waiting until this evening, but i am going to prepare things ... :) Thank for your feedback! Greetings, bu5hm4n On Mon, Jun 11, 2018 at 4:26 PM, Marcel Hollerbach wrote: Okay, we need to step back with this a bit. The problem is, workboards are quite unmanagable, and clearly not made for the amount of tickets we are having. So here a new proposal: I create the following projects: efl-ecore (additionally: elput & ecore_*) efl-eina (additionally: evil emile) efl-eo efl-eolian efl-edje (additionally: ephysics embryo) efl-evas (additionally ector) efl-elementary (additionally: ethumb, emotion & elocation) efl-eldbus efl-eio efl-efreet efl-sys (additionally: eeze) efl-eet Each project gets automatically added efl to it. The tags can be added to each ticket. Opinions? Greetings, bu5hm4n On 06/11/2018 05:54 AM, Hermet Park wrote: good to go. On Sat, Jun 9, 2018 at 12:47 AM, Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: This seems like something which would help people more easily find issues that they can contribute to. Perhaps a 5th workboard for something like 'main loop' could also be added? On Fri, Jun 8, 2018 at 11:32 AM Marcel Hollerbach wrote: Hello, as Mike said, here my proposal for handling bugs for the upcoming release: i) Every bug will get a difficulty assigned either Easy, Difficult, or Impossible, this is to ensure that new people, and people that don't know the subsystem or context very well can also help bugfixing. ii) I am going to create 4 new workboards: - primitives: Stuff that has its root problems in eina, eo, (low in our software stack) - interfaces: A Bug is caused due to the movement to a different namespace, refactoring into new classes, or changes related to new efl_* code / classes. - rendering: A Bug is located in the engine code for some protocol/platform - widgets: Your usage of elm widgets broke somewhere between efl-1.20 and the current state. iii) If you work on a bug, claim it for you. If a other bug sneaks in between, or there is no time in the next week or so: Document your findings, and remove your name from the assignee field on phabricator, so someone else might work on the bug. Any objections ? For Monday I am planning to go through the bugtracker trying to assign difficulities, and workboards. Greetings, bu5hm4n -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Stuff
Neat, do you have any plans to update the documentation for BSD on the site? On Sat, Jun 9, 2018 at 3:27 PM Al Poole wrote: > Hi all, > > Always talked about doing an OpenBSD installer with the EFL/E stack. > > So I did one, and it works! > > If you're interested: > > http://bogosys.org/openbsd.html > > Should install on all amd64 machines (EFI/MBR). If you choose to > enable xdm E will be the WM of choice, and if not, startx and E will > be the WM of choice. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Stuff
Absolutely. Am not really sure where to start there. I've all the instructions etc ready, but it's definitely better if we host it. Can you advise? On Mon, Jun 11, 2018 at 11:18 AM, Mike Blumenkrantz wrote: > Neat, do you have any plans to update the documentation for BSD on the site? > > On Sat, Jun 9, 2018 at 3:27 PM Al Poole wrote: > >> Hi all, >> >> Always talked about doing an OpenBSD installer with the EFL/E stack. >> >> So I did one, and it works! >> >> If you're interested: >> >> http://bogosys.org/openbsd.html >> >> Should install on all amd64 machines (EFI/MBR). If you choose to >> enable xdm E will be the WM of choice, and if not, startx and E will >> be the WM of choice. >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Stuff
Ask Xavi on IRC On Mon, Jun 11, 2018 at 6:56 AM Al Poole wrote: > Absolutely. > > Am not really sure where to start there. I've all the instructions etc > ready, but it's definitely better if we host it. > > Can you advise? > > On Mon, Jun 11, 2018 at 11:18 AM, Mike Blumenkrantz > wrote: > > Neat, do you have any plans to update the documentation for BSD on the > site? > > > > On Sat, Jun 9, 2018 at 3:27 PM Al Poole wrote: > > > >> Hi all, > >> > >> Always talked about doing an OpenBSD installer with the EFL/E stack. > >> > >> So I did one, and it works! > >> > >> If you're interested: > >> > >> http://bogosys.org/openbsd.html > >> > >> Should install on all amd64 machines (EFI/MBR). If you choose to > >> enable xdm E will be the WM of choice, and if not, startx and E will > >> be the WM of choice. > >> > >> > >> > -- > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Stuff
Will do - thanks! On Mon, Jun 11, 2018 at 11:59 AM, Mike Blumenkrantz wrote: > Ask Xavi on IRC > > On Mon, Jun 11, 2018 at 6:56 AM Al Poole wrote: > >> Absolutely. >> >> Am not really sure where to start there. I've all the instructions etc >> ready, but it's definitely better if we host it. >> >> Can you advise? >> >> On Mon, Jun 11, 2018 at 11:18 AM, Mike Blumenkrantz >> wrote: >> > Neat, do you have any plans to update the documentation for BSD on the >> site? >> > >> > On Sat, Jun 9, 2018 at 3:27 PM Al Poole wrote: >> > >> >> Hi all, >> >> >> >> Always talked about doing an OpenBSD installer with the EFL/E stack. >> >> >> >> So I did one, and it works! >> >> >> >> If you're interested: >> >> >> >> http://bogosys.org/openbsd.html >> >> >> >> Should install on all amd64 machines (EFI/MBR). If you choose to >> >> enable xdm E will be the WM of choice, and if not, startx and E will >> >> be the WM of choice. >> >> >> >> >> >> >> -- >> >> Check out the vibrant tech community on one of the world's most >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> ___ >> >> enlightenment-devel mailing list >> >> enlightenment-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> >> > >> -- >> > Check out the vibrant tech community on one of the world's most >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> > ___ >> > enlightenment-devel mailing list >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release Handling
As said in discussion on IRC, grouping by library does nothing to reduce the bucket size here, so this is a false premise. Grouping by overall functional component, as proposed by Hermet, will provide better workflows, and we can create sub-projects for these components (effectively sub sub-projects) to further pare down the number of tickets per bucket. On Mon, Jun 11, 2018 at 6:18 AM Marcel Hollerbach wrote: > Mike came up with the idea of sub projects, which sounds very good to me. > > On 06/11/2018 10:17 AM, Hermet Park wrote: > > Imho, base infrastructure (eo/eina/efl) / rendering (evas, ector) / > layout > > (edje, eet) / core system (ecore family) / window system / widgets > (elm) / > > sys-helpers (efreet, eldbus, eeze... ) is enough ... > > Probably true, however, i would like to have them in even smaller > projects, so its easier to find relevant tickets for one specific > subsystem ... :) I think a project with 10 tickets is easier to maintain > and look at instead of 100 tickets ... :) > > > > > But, your proposal is not arguable neither. I agree on it. > > > > The problem is, sometimes issues aren't independent by modules nor clear > to > > list up... > > That is the reason i want to use projects tags now, you can add multiple > projects (like efl-ecore efl-evas efl-elementary). > > > > > anyway, good to go! > > Waiting until this evening, but i am going to prepare things ... :) > > Thank for your feedback! > > > Greetings, > bu5hm4n > > > > > > On Mon, Jun 11, 2018 at 4:26 PM, Marcel Hollerbach > wrote: > > > >> Okay, we need to step back with this a bit. > >> > >> The problem is, workboards are quite unmanagable, and clearly not made > for > >> the amount of tickets we are having. > >> > >> So here a new proposal: > >> I create the following projects: > >> > >> efl-ecore (additionally: elput & ecore_*) > >> efl-eina (additionally: evil emile) > >> efl-eo > >> efl-eolian > >> efl-edje (additionally: ephysics embryo) > >> efl-evas (additionally ector) > >> efl-elementary (additionally: ethumb, emotion & elocation) > >> efl-eldbus > >> efl-eio > >> efl-efreet > >> efl-sys (additionally: eeze) > >> efl-eet > >> > >> Each project gets automatically added efl to it. The tags can be added > to > >> each ticket. > >> > >> Opinions? > >> > >> Greetings, > >> bu5hm4n > >> > >> > >> On 06/11/2018 05:54 AM, Hermet Park wrote: > >> > >>> good to go. > >>> > >>> On Sat, Jun 9, 2018 at 12:47 AM, Mike Blumenkrantz < > >>> michael.blumenkra...@gmail.com> wrote: > >>> > >>> This seems like something which would help people more easily find > issues > that they can contribute to. Perhaps a 5th workboard for something > like > 'main loop' could also be added? > > On Fri, Jun 8, 2018 at 11:32 AM Marcel Hollerbach > wrote: > > Hello, > > > > as Mike said, here my proposal for handling bugs for the upcoming > > > release: > > > > > i) Every bug will get a difficulty assigned either Easy, Difficult, > or > > Impossible, this is to ensure that new people, and people that don't > > know the subsystem or context very well can also help bugfixing. > > > > ii) I am going to create 4 new workboards: > > - primitives: Stuff that has its root problems in eina, eo, (low in > our > > software stack) > > - interfaces: A Bug is caused due to the movement to a different > > namespace, refactoring into new classes, or changes related to new > efl_* > > code / classes. > > - rendering: A Bug is located in the engine code for some > > > protocol/platform > > > - widgets: Your usage of elm widgets broke somewhere between efl-1.20 > > and the current state. > > > > iii) If you work on a bug, claim it for you. If a other bug sneaks in > > between, or there is no time in the next week or so: Document your > > findings, and remove your name from the assignee field on > phabricator, > > so someone else might work on the bug. > > > > Any objections ? For Monday I am planning to go through the > bugtracker > > trying to assign difficulities, and workboards. > > > > Greetings, > > bu5hm4n > > > > > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot >
Re: [E-devel] Release Handling
Okay, after another discussion on ml, we start with those groups: - data types: Everything related to defined data types and the functions therefore, (includes Eos base object) - main loop: loop, idlers, jobs, - rendering: engine related things - layout: edje objects, boxes, tables, everything that positions child objects for you. - display system: cocoa, xserver, wayland, windows engine, drm, fb related things - widgets: Bugs in widgets - system integration: dbus, files, session variables, process execution things - language bindings: I think this is self explaining - networking: ecore_con and file download things - input: input methods and everything where input can come from. Greetings, bu5hm4n On 06/11/2018 02:46 PM, Mike Blumenkrantz wrote: As said in discussion on IRC, grouping by library does nothing to reduce the bucket size here, so this is a false premise. Grouping by overall functional component, as proposed by Hermet, will provide better workflows, and we can create sub-projects for these components (effectively sub sub-projects) to further pare down the number of tickets per bucket. On Mon, Jun 11, 2018 at 6:18 AM Marcel Hollerbach wrote: Mike came up with the idea of sub projects, which sounds very good to me. On 06/11/2018 10:17 AM, Hermet Park wrote: Imho, base infrastructure (eo/eina/efl) / rendering (evas, ector) / layout (edje, eet) / core system (ecore family) / window system / widgets (elm) / sys-helpers (efreet, eldbus, eeze... ) is enough ... Probably true, however, i would like to have them in even smaller projects, so its easier to find relevant tickets for one specific subsystem ... :) I think a project with 10 tickets is easier to maintain and look at instead of 100 tickets ... :) But, your proposal is not arguable neither. I agree on it. The problem is, sometimes issues aren't independent by modules nor clear to list up... That is the reason i want to use projects tags now, you can add multiple projects (like efl-ecore efl-evas efl-elementary). anyway, good to go! Waiting until this evening, but i am going to prepare things ... :) Thank for your feedback! Greetings, bu5hm4n On Mon, Jun 11, 2018 at 4:26 PM, Marcel Hollerbach wrote: Okay, we need to step back with this a bit. The problem is, workboards are quite unmanagable, and clearly not made for the amount of tickets we are having. So here a new proposal: I create the following projects: efl-ecore (additionally: elput & ecore_*) efl-eina (additionally: evil emile) efl-eo efl-eolian efl-edje (additionally: ephysics embryo) efl-evas (additionally ector) efl-elementary (additionally: ethumb, emotion & elocation) efl-eldbus efl-eio efl-efreet efl-sys (additionally: eeze) efl-eet Each project gets automatically added efl to it. The tags can be added to each ticket. Opinions? Greetings, bu5hm4n On 06/11/2018 05:54 AM, Hermet Park wrote: good to go. On Sat, Jun 9, 2018 at 12:47 AM, Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: This seems like something which would help people more easily find issues that they can contribute to. Perhaps a 5th workboard for something like 'main loop' could also be added? On Fri, Jun 8, 2018 at 11:32 AM Marcel Hollerbach wrote: Hello, as Mike said, here my proposal for handling bugs for the upcoming release: i) Every bug will get a difficulty assigned either Easy, Difficult, or Impossible, this is to ensure that new people, and people that don't know the subsystem or context very well can also help bugfixing. ii) I am going to create 4 new workboards: - primitives: Stuff that has its root problems in eina, eo, (low in our software stack) - interfaces: A Bug is caused due to the movement to a different namespace, refactoring into new classes, or changes related to new efl_* code / classes. - rendering: A Bug is located in the engine code for some protocol/platform - widgets: Your usage of elm widgets broke somewhere between efl-1.20 and the current state. iii) If you work on a bug, claim it for you. If a other bug sneaks in between, or there is no time in the next week or so: Document your findings, and remove your name from the assignee field on phabricator, so someone else might work on the bug. Any objections ? For Monday I am planning to go through the bugtracker trying to assign difficulities, and workboards. Greetings, bu5hm4n -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most
Re: [E-devel] Release Handling
Let's split this into a separate thread from now on... On Mon, Jun 11, 2018 at 9:39 AM Marcel Hollerbach wrote: > Okay, after another discussion on ml, we start with those groups: > > - data types: Everything related to defined data types and the functions > therefore, (includes Eos base object) > > - main loop: loop, idlers, jobs, > > - rendering: engine related things > > - layout: edje objects, boxes, tables, everything that positions child > objects for you. > > - display system: cocoa, xserver, wayland, windows engine, drm, fb > related things > > - widgets: Bugs in widgets > > - system integration: dbus, files, session variables, process execution > things > > - language bindings: I think this is self explaining > > - networking: ecore_con and file download things > > - input: input methods and everything where input can come from. > > Greetings, > bu5hm4n > > On 06/11/2018 02:46 PM, Mike Blumenkrantz wrote: > > As said in discussion on IRC, grouping by library does nothing to reduce > > the bucket size here, so this is a false premise. Grouping by overall > > functional component, as proposed by Hermet, will provide better > workflows, > > and we can create sub-projects for these components (effectively sub > > sub-projects) to further pare down the number of tickets per bucket. > > > > On Mon, Jun 11, 2018 at 6:18 AM Marcel Hollerbach > wrote: > > > >> Mike came up with the idea of sub projects, which sounds very good to > me. > >> > >> On 06/11/2018 10:17 AM, Hermet Park wrote: > >>> Imho, base infrastructure (eo/eina/efl) / rendering (evas, ector) / > >> layout > >>> (edje, eet) / core system (ecore family) / window system / widgets > >> (elm) / > >>> sys-helpers (efreet, eldbus, eeze... ) is enough ... > >> > >> Probably true, however, i would like to have them in even smaller > >> projects, so its easier to find relevant tickets for one specific > >> subsystem ... :) I think a project with 10 tickets is easier to maintain > >> and look at instead of 100 tickets ... :) > >> > >>> > >>> But, your proposal is not arguable neither. I agree on it. > >>> > >>> The problem is, sometimes issues aren't independent by modules nor > clear > >> to > >>> list up... > >> > >> That is the reason i want to use projects tags now, you can add multiple > >> projects (like efl-ecore efl-evas efl-elementary). > >> > >>> > >>> anyway, good to go! > >> > >> Waiting until this evening, but i am going to prepare things ... :) > >> > >> Thank for your feedback! > >> > >> > >> Greetings, > >> bu5hm4n > >> > >> > >>> > >>> On Mon, Jun 11, 2018 at 4:26 PM, Marcel Hollerbach > >> wrote: > >>> > Okay, we need to step back with this a bit. > > The problem is, workboards are quite unmanagable, and clearly not made > >> for > the amount of tickets we are having. > > So here a new proposal: > I create the following projects: > > efl-ecore (additionally: elput & ecore_*) > efl-eina (additionally: evil emile) > efl-eo > efl-eolian > efl-edje (additionally: ephysics embryo) > efl-evas (additionally ector) > efl-elementary (additionally: ethumb, emotion & elocation) > efl-eldbus > efl-eio > efl-efreet > efl-sys (additionally: eeze) > efl-eet > > Each project gets automatically added efl to it. The tags can be added > >> to > each ticket. > > Opinions? > > Greetings, > bu5hm4n > > > On 06/11/2018 05:54 AM, Hermet Park wrote: > > > good to go. > > > > On Sat, Jun 9, 2018 at 12:47 AM, Mike Blumenkrantz < > > michael.blumenkra...@gmail.com> wrote: > > > > This seems like something which would help people more easily find > >> issues > >> that they can contribute to. Perhaps a 5th workboard for something > >> like > >> 'main loop' could also be added? > >> > >> On Fri, Jun 8, 2018 at 11:32 AM Marcel Hollerbach > >> wrote: > >> > >> Hello, > >>> > >>> as Mike said, here my proposal for handling bugs for the upcoming > >>> > >> release: > >> > >>> > >>> i) Every bug will get a difficulty assigned either Easy, Difficult, > >> or > >>> Impossible, this is to ensure that new people, and people that > don't > >>> know the subsystem or context very well can also help bugfixing. > >>> > >>> ii) I am going to create 4 new workboards: > >>> - primitives: Stuff that has its root problems in eina, eo, (low in > >> our > >>> software stack) > >>> - interfaces: A Bug is caused due to the movement to a different > >>> namespace, refactoring into new classes, or changes related to new > >> efl_* > >>> code / classes. > >>> - rendering: A Bug is located in the engine code for some > >>> > >> protocol/platform > >> > >>> - widgets: Your usage of elm widgets broke somewhere between > efl-1.20 > >>> and the current state. > >>> > >>>
[E-devel] Project tags
Hi, In accordance with various discussions on IRC and some tangential discussion in the [release handling] thread, subprojects for efl have been created: https://phab.enlightenment.org/project/subprojects/2/ We're currently working to tag all existing tickets (moved to https://phab.enlightenment.org/project/view/208/ currently) with these subprojects. If anyone has time, please try to help out with this. Thanks, Mike -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Project tags
This process is now complete. Most tickets have been migrated to a subproject of the 'efl' project in order to improve the workflow of managing tickets. Big thanks to everyone who pitched in to help move 700+ tickets in only a couple hours! On Mon, Jun 11, 2018 at 9:48 AM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Hi, > > In accordance with various discussions on IRC and some tangential > discussion in the [release handling] thread, subprojects for efl have been > created: https://phab.enlightenment.org/project/subprojects/2/ > > We're currently working to tag all existing tickets (moved to > https://phab.enlightenment.org/project/view/208/ currently) with these > subprojects. If anyone has time, please try to help out with this. > > Thanks, > Mike > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EFL Alpha Release: Action Required
Hi, I'd like to attempt an alpha release by end of next week (22 June 2018) at latest. The following action should be taken by all active contributors: * Examine the list of high priority tickets and see if there is anything you can help with https://phab.enlightenment.org/maniphest/query/C.4F6YJs0qVJ/#R * Examine the list of incoming tickets and see if there is anything you can help with or triage https://phab.enlightenment.org/maniphest/query/.A.JB1lE_L6b/#R * Check tickets assigned to you to see if there are any tickets which should be triaged to a different priority Ideally we should have a good idea of where things stand within a few days so we can determine what needs to be fixed before an alpha goes out. Regards, Mike -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
